Internet Protocol (IP) networks are increasingly used as universal supports for a multitude of services and applications. The IP has had a federator role for many operators opting for this protocol to mutualize previously disparate service offers.
The IPv4 version of the Internet Protocol has been in use for some years.
To satisfy constraints imposed by such communications services and more particularly to accommodate increased requirements in terms of addresses, operators and network equipment manufacturers have united to specify a new generation communications protocol, known as IPv6, defined by specifications and analysis documents that are now at a sufficiently advanced stage of development for it to be possible to envisage operational deployment in the operators' networks.
Nevertheless, the introduction of this new generation protocol is causing significant problems linked to the need to guarantee interoperability and interworking between the IPv6 protocol and the IPv4 protocol already deployed in IP networks. In the current state of the art solutions to those problems have been identified, but they have the disadvantage that they are operative not only at a “service” level (in particular in the application layer) but also at a “transport” level (in the IP layer). In the transport layer, mechanisms have been proposed and even standardized by the Internet Engineering Task Force (IETF), such as the NAT-PT (Network Address Translation—Protocol Translation) technique and various tunneling techniques that encapsulate IPv6 data in IPv4 datagrams or vice-versa.
Furthermore, architectures and service platforms must be updated and adapted to enable interworking between clients situated in IP environments of different types (IPv4 and IPv6) as transparently as possible for the end user.
Among other multimedia activities, the IETF has standardized the Session Initiation Protocol (SIP), the main functions of which are initiating, modifying, and terminating multimedia sessions. The SIP is an interesting example for application of the present invention. It is based on the Service Description Protocol (SDP) for producing a description of parameters relating to the session concerned. Once negotiation between two parties to a call has succeeded, the parties can exchange media streams by activating a Real-time Transport Protocol (RTP). RTP session parameters are prenegotiated via SIP signaling messages, notably in the SDP part. They are mainly termination addresses and port numbers to be used at either end of a communications link to be set up.
Since a first version of the SIP was described in Request For Comments (RFC) 2543 it has been compatible with IPv6. In theory, an implementation of the SIP easily decodes IPv4 and IPv6 addresses, which can be introduced into specific fields such as a “CONTACT” header or headers of the SDP part. However, the presence of such addresses can prevent SIP calls being set up if both terminals cannot be contacted in the same IP environment, i.e. if one has an IPv4 address and the other an IPv6 address. Thus when an IPv4 user agent A initiates an SIP session with an IPv6 user agent registered with an IPv4 location server (also known as a “Registrar” R), the resulting exchange of SIP messages is as shown in FIG. 1a, in which a first user agent A seeking to contact a second user agent B sends an “INVITE” message to a proxy server PS using an IPv4 address specific to it. Here the proxy server PS is attached to an IPv4-only environment. Once the message has been received by the proxy server PS, the proxy server submits a query to a location server, also known as a registration server, to recover the address of the second user agent B. Under the present assumption, that address is an IPv6 address and the proxy server PS does not know a route to that destination, given that the proxy server PS is of IPv4-only type. An error message is then sent to the user agent A indicating that it is impossible to set up an SIP session between the first and second user agents A and B. This error message is the “(2) 404 No Route” message shown in FIG. 1a. 
If it is now assumed that the proxy server PS can nevertheless contact the location address of the first user agent A as well as that of the second user agent B, another exchange of SIP messages takes place, with the second user agent B attempting to call the first user agent A, as shown in FIG. 1b. 
In this situation, the proxy server PS routes an “INVITE” message received form the second user agent B to the location address of the first user agent A. This “INVITE” message contains an SDP offer describing, in addition to the codecs (coders/decoders) offered by the first user agent B, an RTP port number and an address that the second user agent B can use to send and receive RTP streams. In FIG. 1b, that address is an IPv6 address. Thus when the user agent A receives this “INVITE” message, it can only refuse to open the session because it is an IPv4 client. Depending on how it is implemented, it can at best send back an error message indicating that it does not support network connections to the IP address of the user agent B. Thus SIP sessions cannot be set up in either of the above examples described with reference to FIGS. 1a and 1b. 
Coexistence of IP addresses of different types can affect calls other than those graphically represented and described above. Thus calls to Dual Stack (DS) clients can also fail to terminate in the exchange of media streams, DS user agents being able to process both IPv4 and IPv6 address types. This is because the basic SIP provides for indicating only one IP address for sending or receiving media streams. To overcome this problem, RFC 4092 introduces new semantic features including an “sdp-anat” flag to enable a user agent to announce and/or discover one or more address types. Thus DS user agents can indicate in their STP offer both their IPv4 address and their IPv6 address. By means of this technique, all calls from or to a DS user agent to or from single-version clients (i.e. clients compatible only with the IPv4 protocol or only with the IPv6 protocol) can terminate in successful SIP sessions. However, these semantic features are reserved exclusively for DS user agents, and therefore offer no solution for successfully setting up sessions between single-version clients.
In the particular situation where two nodes at the ends of a communications link intended to convey a given call are single-version nodes, the SIP telephone service operator concerned can use application level gateway (ALG) applications for modifying SDP offers to ensure consistency between the address type supported and the type contained in the received SIP messages. To this end SIP servers use information relating to the transport layer, and not specific to the SIP, to route calls or to decide to use ALG applications to change the content of the SDP offers. Such behavior of SIP servers is not covered by the standard.
Generally speaking, the problem linked to interconnecting two heterogeneous user agents (i.e. user agents of different IP types) has not been studied in detail by the telecommunications community. In particular, apart from an ANAT proposal described in RFC 4091 and RFC 4092, which solves part of the problem, there is no IETF document describing the behavior of SIP servers for routing calls connecting two user agents in two different IP environments.
Furthermore, the existing techniques have the following drawbacks:                using ALG applications and additional functions is not documented; the proxy server PS has no means specified by RFC 3261 to facilitate this task; furthermore, this use of ALG applications and additional adaptation functions burdens the tasks accomplished in the network;        the proxy server PS must use information from the network layer (also referred to in the present document as the transport layer) to make decisions concerning the service layer; it must therefore take into account considerations other than the source address of the messages, the address used to contact the proxy server or to examine the SDP part; this risks degrading the performance of the proxy, which is configured a priori to process only service level information;        the solution is not generic: the philosophy of call routing and intervention by the proxy server PS depends on the interconnection solution deployed at the transport level;        routing calls relies on discriminating clients: to route calls between heterogeneous nodes, the proxy server needs to know the calling and called node types (IPv4, IPv6 or DS); the complexity of recovering this information can degrade call performance.        
The work of the inventors has lead them to conclude that, not withstanding a need that emerges from the above study, in the current state of the art there is no way for a proxy server to successfully route a call to a remote node without first determining the called node type, which explains why most techniques for managing calls between heterogeneous nodes currently under study are insufficient and do not address service requirements enabling heterogeneous calls.